On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
I don't really agree with that characterization. To state my understanding,
as responsible AD, of the status of this document: this document is in the
RFC Editor's queue being processed.
That was a process mistake.
1) ekr filed a DISCUSS
2) other pe
On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>
> I don't really agree with that characterization. To state my
>> understanding,
>> as responsible AD, of the status of this document: this document is in the
>> RFC Editor's queue being processed
Hi Richard,
I work in the IoT space and am interested in handshakes that involve little
computation but offer better protection than symmetric PSK in the event of
server breach.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54
[…]
We would love to h
On Thu, 12 Apr 2018, Richard Barnes wrote:
The question Ben was asking, though, is whether the impact of that process
mistake is serious enough to merit pulling back the doc from the RFC editor.
That can only be answered after the consensus call. I don't think anyone
is really objecting as lo
On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters wrote:
> On Thu, 12 Apr 2018, Richard Barnes wrote:
>
> The question Ben was asking, though, is whether the impact of that process
>> mistake is serious enough to merit pulling back the doc from the RFC editor.
>>
>
> That can only be answered after t
There's a few steps Paul is missing in his summary of the process.
On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote:
>
>
> On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
>>
>> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>>
>>> I don't really agree with that characterization. To state
I requested that the RFC editor add TLS and DTLS to their list of well-known
abbreviations [0]. They agreed so now draft editors are free to expand (or
not) TLS and DTLS in drafts. Note that the RFC editor also added SSL and
SSL/TLS to the list.
spt
[0] https://www.rfc-editor.org/materials/a
On Thu, Apr 12, 2018 at 09:50:20AM -0400, Kathleen Moriarty wrote:
> There's a few steps Paul is missing in his summary of the process.
>
> On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote:
> >
> >
> > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
> >>
> >> On Wed, 11 Apr 2018, Benja
Sorry for being confusing. I meant to say full Denial of Existing is in
the draft implicitly already (because of the reference to DANE
authentication according to RFC6698 and RFC7671 (which do mention it) in
Section 6).
I do like the idea of STS for this extension (and augment it with the
more r
> On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote:
>
> If the answer to 1) is no then please indicate if you think the working group
> should work on the document to include
>
> A) Recommendation of adding denial of existence proofs in the chain provided
> by the extension
> B) Adding sign
> * The present text (Section 8) says:
>
> Green field applications that are designed to always employ this
>extension, could of course unconditionally mandate its use.
>
> Therefore such "green field" applications (presumably some of the ones
> ready to implement now) effe
> On Apr 12, 2018, at 2:20 PM, Willem Toorop wrote:
>
> I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
> [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL
> conveyed in a ServerHello message secure when it would be just for SSL?
The reason for that of cours
On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote:
> Sorry for being confusing. I meant to say full Denial of Existing is in
> the draft implicitly already (because of the reference to DANE
> authentication according to RFC6698 and RFC7671 (which do mention it) in
> Section 6).
>
>
>
> On Apr 12, 2018, at 2:44 PM, John Gilmore wrote:
>
> If any ever did, the future RFC could specify
> how servers which do not have validated TLSA records should handle the
> situation.
They'd have to violate the text of this draft:
> Different future protocols might choose different ways
>
> On Apr 12, 2018, at 2:44 PM, John Gilmore wrote:
>
> Viktor, I believe you have confused a "could" with a "mandate".
As to this point, I'm not now and have never been confused about
that. The present draft, as explained upthread, perhaps in too
many ways and in too many words, offers no val
On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
> I'm waiting to see if anything else comes out of this thread.
> In particular, I am hoping that some authors/proponents of leaving the
> document in the RFC Editor queue would speak to the question of the
> target scope, given the arguments that have been
If this is indeed about adding [goo], what prevents Viktor or Paul
from proposing a new addition to the protocol in the form of a new I-D
that enacts the changes they wish to see?
On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore
wrote:
> On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
>> I'm waiting to s
This is in fact what I proposed in the room in London. Let's publish draft
this as-is, and handle what they want as a follow-on.
On Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson
wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the pro
On 4/12/18 1:47 PM, Martin Thomson wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Clearly nothing, and I think this would be a reasonable way forward.
> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote:
>
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Why publish a crippled specification that needs immed
On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes t
On Fri, Apr 13, 2018 at 8:09 AM, Viktor Dukhovni wrote:
>> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote:
>>
>> If this is indeed about adding [goo], what prevents Viktor or Paul
>> from proposing a new addition to the protocol in the form of a new I-D
>> that enacts the changes they wish to
Op 13-04-18 om 00:09 schreef Viktor Dukhovni:
> The protocol as described prohibits denial of existence responses. Willem
> acknowledged (thus far in an off-list message) that that's an oversight that
> should be corrected, and such a correction is the substance of option (A).
Well... I find it u
> "RB" == Richard Barnes writes:
RB> It seems noteworthy, however, that nobody is chiming in on the list who was
RB> not also part of the discussion in the room.
Not true.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
TLS mailing
> On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote:
>
> Well... I find it unfortunate that the line you were quoting from
> section 3.4 could be interpreted as prohibiting the possibility of
> denial of existence. So I am open to relaxing that text so that it can
> not be interpreted as such a
On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes t
On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote:
> >
> > Well... I find it unfortunate that the line you were quoting from
> > section 3.4 could be interpreted as prohibiting the possibility of
> > denial of existence. So I am ope
> On Apr 12, 2018, at 6:34 PM, Shumon Huque wrote:
>
> Implementers that are opposed to pinning would then just ignore this second
> draft (and not bother with the authenticated denial part of the first draft).
The pin hint is NOT an obligation on the client or the server. It is OPTIONAL.
Se
> On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote:
>
> The difficulty here is what the server knows about the clients behavior.
> Specifically, if the server serves TLSA records and then ceases doing
> without serving authenticated denial of existence, then it is unable to
> determine if this
On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote:
> >
> > The difficulty here is what the server knows about the clients behavior.
> > Specifically, if the server serves TLSA records and then ceases doing
> > without serving authent
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote:
>
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *cou
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote:
>
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *cou
Hi everyone,
Below is a pointer to a new I-D describing an approach for clients to request
session tickets via a new post-handshake message. This is useful for
applications that perform parallel connection establishment and racing, e.g.,
via Happy Eyeballs. It should also help reduce ticket was
Hi Chris,
Thanks for sharing this. It's a simple idea and seems generally useful.
Do you have a use for the identifier and context? I can see that
without them there is no way to distinguish between a response to a
request and spontaneous ticket issuance, but I just can't see how that
is a prob
Scrub the bit about needing the extension. I read past Section 4
completely. The other comments are still relevant.
On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson
wrote:
> Hi Chris,
>
> Thanks for sharing this. It's a simple idea and seems generally useful.
>
> Do you have a use for the ident
Hi Martin,
Please see inline below.
> On Apr 12, 2018, at 8:53 PM, Martin Thomson wrote:
>
> Scrub the bit about needing the extension. I read past Section 4
> completely. The other comments are still relevant.
No problem.
>
> On Fri, Apr 13, 2018 at 1:49 PM, Martin Thomson
> wrote:
>>
>
On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood
wrote:
> Yes — we’re currently working on an I-D that would use the context for
> “special” tickets. Depending on where that goes, if anywhere, we may or may
> not need to keep the context. As you suggest, distinguishing between
> responses and
On 4/12/18 6:55 PM, Viktor Dukhovni wrote:
> If you'd like me to craft revised option (A) text, that includes a suitable
> caveat, I can try.
I'm okay with putting denial-of-existence in there as a should,
but I do feel strongly that pinning belongs in a separate document.
As I said earlier, I
> On Apr 12, 2018, at 9:07 PM, Martin Thomson wrote:
>
> On Fri, Apr 13, 2018 at 1:55 PM, Christopher Wood
> wrote:
>> Yes — we’re currently working on an I-D that would use the context for
>> “special” tickets. Depending on where that goes, if anywhere, we may or may
>> not need to keep the
> On Apr 13, 2018, at 12:07 AM, Melinda Shore
> wrote:
>
> I'm okay with putting denial-of-existence in there as a should,
> but I do feel strongly that pinning belongs in a separate document.
> As I said earlier, I have a problem with putting features in protocols
> that nobody intends to us
On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni
wrote:
>
> > On Apr 13, 2018, at 12:07 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > I'm okay with putting denial-of-existence in there as a should,
> > but I do feel strongly that pinning belongs in a separate document.
> > As
> On Apr 13, 2018, at 12:51 AM, Eric Rescorla wrote:
>
> Thanks for pointing this out. I agree that this text is likely to cause
> interop problems and should be removed or at least scoped out in
> the case where client and server are unrelated. I regret that I didn't
> catch it during my IESG
42 matches
Mail list logo
