Subject: Re: [Isms] SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 6 Jan 2010 20:33:52 -0800

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, December 30, 2009 8:08 AM
> To: David Harrington
> Cc: 'tom.petch'; 'Wes Hardaker'; Joseph Salowey (jsalowey); 
> [email-masked]
> Subject: Re: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt
> 
> >>>>> On Wed, 30 Dec 2009 10:31:53 -0500, "David Harrington" 
> <[email-masked]> said:
> 
> DH> Personally, I recommend against having a reference to the bis 
> DH> document. We are in WGLC and don't want publication held 
> up because 
> DH> of a reference to bis.
> 
> I agree; I was trying not to specify which versions of the 
> TLS based protocols we are requiring because I don't think 
> there are any features of the newer ones that we need.  There 
> is no reason that future versions of TLS and DTLS couldn't be 
> used as well assuming they didn't introduce a technical 
> conflict with our document, which is unlikely.

[Joe] Agreed, referencing the current RFC should be fine.  
> --
> Wes Hardaker
> Cobham Analytic Solutions
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 6 Jan 2010 20:46:52 -0800

The TLS extensions draft is in IESG review.  I believe there have been
some issues raised with the SNI, I need to follow up to see if they
require substantial changes to the document.  In any case the revision
would need to be backward compatible with what is in 4366, if you were
going to define a new name type then there may be additional
considerations.  

Joe

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, December 31, 2009 5:02 AM
> To: 'tom.petch'; 'Wes Hardaker'
> Cc: Joseph Salowey (jsalowey); [email-masked]; 'Pasi Eronen'
> Subject: RE: SNI was IsmsReview of draft-ietf-isms-dtls-tm-01.txt
> 
> My experience tells me that getting a document through the 
> IESG approval process can take a year, more likely 6 months. 
> If the bis status changes we can always change the reference 
> later. But I don't get the sense that the bis will beat our 
> document through the system, so I would prefer to point to 
> the stable document unless, as Juergen points out, there is a 
> real technical  distinction.
> 
> dbh
> 
> > From: tom.petch [mailto:[email-masked]]
> > Sent: Thursday, December 31, 2009 3:32 AM
> > To: Wes Hardaker
> > Cc: David Harrington; 'Joseph Salowey (jsalowey)'; 
> [email-masked]; Pasi 
> > Eronen
> > ----- Original Message -----
> > From: "Wes Hardaker" <[email-masked]>
> > Sent: Wednesday, December 30, 2009 5:36 PM
> > > >>>>> On Wed, 30 Dec 2009 08:07:45 -0800, Wes Hardaker
> > <[email-masked]>
> > said:
> > >
> > > DH> document. We are in WGLC and don't want publication
> > held up because of
> > > DH> a reference to bis.
> > >
> > > WH> I agree; I was trying not to specify which versions of
> > the TLS based
> > > WH> protocols we are requiring because I don't think there
> > are any features
> > > WH> of the newer ones that we need.  There is no reason
> > that future versions
> > > WH> of TLS and DTLS couldn't be used as well assuming they
> > didn't introduce
> > > WH> a technical conflict with our document, which is unlikely.
> > >
> > > Whoops.  Having re-read everything I realized I was
> > confused about which
> > > of the two issues David was talking about.  I responded
> > about the DTLS
> > > reference but the discussion was surrounding the fact that
> > RFC4366 is
> > > the only RFC that documents the server name extension until
> > a new one
> > > gets published.  Because of that, we'd either have to keep
> > referencing
> > > the older one (which doesn't cause any technical problems
> > that I'm aware
> > > of) or reference the ID and hope it completes soon.  Pasi may have
> a
> > > better idea about how the other document is progressing,
> > but unless it's
> > > almost identically timed I don't think it buys us much to
> > reference the ID.
> > 
> > Um
> > 
> > My point was rather that RFC4366 is obsoleted by RFC5246 
> because the 
> > description of the extension technique has been removed 
> from the TLS 
> > extension document and made part of the base document, ie 
> extensions 
> > are base TLS as of TLS 1.2 (a key feature of current TLS list 
> > discussions).
> > 
> > 4366-bis will only contain details of specific extensions.
> > 
> > SNI does appear in both RFC4366 and 4366-bis so from that point of 
> > view, either will do, so it is a choice of being allowed to 
> depend on 
> > an obsoleted document versus having to wait for an I-D to 
> progress - I 
> > think the latter far preferable, the former a short term 
> expedient.  
> > The latter gives us the chance to request another case for SNI, the 
> > current hostname insisting on a fully qualified DNS name 
> which isn't 
> > really right for a securityName.
> > 
> > My personal view is that, currently, the TLS WG is rather 
> preoccupied 
> > with fixing the hole in renegotiation and I expect it will be some 
> > months before 4366bis gets the attention it
> deserves.
> > 
> > Tom Petch
> > 
> > > Wes Hardaker

---

From: "David Harrington" <[email-masked]>
Date: Thu, 7 Jan 2010 08:50:51 -0500

Hi,

If we cite the older version, and the new version gets approved, and
the new version either updates or obsoletes the older version, then
the rfc-editor will probably ask our editors which is the correct
reference.

If we cite the newer version then the rfc-editor will not allow our
document to be published until the new version is approved.

Either way, this can be addressed during the IESG approval/RFC-editor
queue process.

dbh

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Wednesday, January 06, 2010 11:47 PM
> To: David Harrington; tom.petch; Wes Hardaker
> Cc: [email-masked]; Pasi Eronen

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 07 Jan 2010 07:50:32 -0800

>>>>> On Thu, 7 Jan 2010 08:50:51 -0500, "David Harrington" <[email-masked]> said:

DH> Either way, this can be addressed during the IESG approval/RFC-editor
DH> queue process.

Agreed.  I think that's the right change (and the new wording also says
you can use any sort of selection method, not just 4366, to make it
generic since we really don't care which is used).

JS> if you were going to define a new name type then there may be
JS> additional considerations.

We're not.  Though that might be useful, I think if we want to do that
it warrants a new document at this point and probably within the TLS WG
itself anyway.
-- 
Wes Hardaker
Cobham Analytic Solutions